RTL designers currently have no conventional tools available that instruct how to write new RTL code to achieve specific goals. Common specific goals are (i) test coverage goals, (ii) congestion goals, (iii) area goals, (iv) timing goals, (v) power goals (caused by insufficient architectures) and (vi) RTL coding style goals. Currently, the RTL code is initially written and processed (i.e., RTL analysis, synthesis, usage of a related netlist for backend and test tools) before any valuable feedback can be provided to the RTL designer. Due to problems not uncovered until later in the design flow, the RTL code is sometimes changed and steps in the design flow are repeated. The changes and iterations cause inefficient use of valuable resources (i.e., time, people and computation power).
Most of the time, Verilog, VHSIC (Very High Speed Integrated Circuit) Hardware Description Language (VHDL) and other RTL writers have limited knowledge of how the generated RTL code impacts design closure or test. Correlation between issues in design closure/test and the RTL code causing the issues is often not achievable. Sometimes, a correlation between a problem and the RTL code is not identified until late in the design cycle where corrections are expensive.
New circuit designs commonly integrate RTL code that already exists. The integration can be difficult for lack of knowledge if the existing RTL code meets the expected goals (i.e., test, congestion, area, timing, power, and RTL coding style goals) Two categories of existing RTL code are available for integration; legacy RTL code and third-party intellectual property (IP) code. Legacy RTL code is RTL code that has been previously generated for other projects by someone who might not be available anymore. The RTL writer may not know if the legacy RTL code satisfies the expected goals of the current project. Third-party IP code is RTL code generated by another company that sells and distributes certain IP. Again, the RTL writer may not know if the third-party IP code satisfies the expected goals of the current project.
The RTL code is conventionally reviewed manually by a team of engineers following specific criteria (i.e., RTL coding guidelines). The manual review is an inefficient process to analyze RTL code since tens of thousands of lines of code are reviewed making the review difficult. Furthermore, the feedback from such a manual review is commonly very limited. Some RTL code is analyzed automatically and feedback is provided back to the RTL writer. However, (i) conventional automatic analysis does not follow the concept of user-defined goals and (ii) the RTL code must be completed first, and the RTL code is often a major part or the whole design, before the conventional analysis can be performed. As a result, resources are not used efficiently.
Integration of legacy RTL code and/or third-party IP is commonly resource intensive. A considerable amount of time is spent writing the new RTL code to interface and communicate with the existing code. Furthermore, compatibility between the existing RTL code and the defined goals is typically unknown at the time of integration.
A netlist can be analyzed and some feedback can be provided back to the RTL writer by a conventional automated netlist analysis tool. However, correlation between netlist issues back to the RTL code can be very difficult. In addition, valuable resources have already been spent in case RTL code has to be changed to solve the netlist issues. A newly developed netlist can be brought through the backend of a conventional design process and conventional test flows to determine if all design criteria are meet. However, waiting until the back end of the design process is an inefficient approach. Any issues that will lead to RTL code changes or netlist changes will cause certain steps in the design flow to be repeated.
Several issues exist with the conventional approaches to writing new RTL code and integrating existing RTL code. A whole project can be endangered if the RTL code prohibits a successful layout completion, if the power specification is not achieved or if targeted test coverage is not achieved. Valuable resources (i.e., time, people, and computation power) are wasted when RTL code and/or netlists are changed to resolve issues not identified until later in the design flow. RTL designers commonly lack an understanding of design closure/test and how the RTL code impacts backend, design for test and power distribution, making manual checking tedious and sometimes impossible. Furthermore, legacy RTL code and third-party IP RTL code could meet the functional specifications and yet still not satisfy the defined goals established for the project. In a worst-case scenario, the legacy RTL code or third-party IP RTL code purchased or licensed can simply be unusable.